On the Performance of Parametric Polymorphism in Maple

Data Type – Each value is some data object – Operations are implemented separately in a generic module – Same module shared by all the values belonging to each type Object-Oriented Approach DoubleRing := proc(val::float) local Me; Me := module() export v, a, s, m, d, gt, zero, one, coerce, absolute, sine, sqroot; v := val; # Data value of object # Implementations for +, -, *, /, >, etc a := (b) -> DoubleRing(Me:-v + b:-v); s := (b) -> DoubleRing(Me:-v – b:-v); m := (b) -> DoubleRing(Me:-v * b:-v); d := (b) -> DoubleRing(Me:-v / b:-v); gt := (b) -> Me:-v > b:-v; zero := () -> DoubleRing(0.0); coerce := () -> Me:-v; . . . end module: return Me; end proc: Object-Oriented Approach Previous example simulates object-oriented approach by storing the value in the module The exports a, s, m, d correspond to basic arithmetic operations We chose names other than the standard +, -, ×, / for two reasons: – The code looks similar to the original SciGMark (Java does not have operator overloading) – It is not very easy to overload operators in Maple Functions like sine and sqroot are used by the FFT algorithm to replace complex operations Abstract Data Type ApproachData Type Approach DoubleRing := module() export a, s, m, d, gt, zero, one, coerce, absolute, sine, sqroot; # Implementations for +, -, *, /, >, etc a := (a, b) -> a + b; s := (a, b) -> a – b; m := (a, b) -> a * b; d := (a, b) -> a / b; gt := (a, b) -> a > b; zero := () -> 0.0; one := () -> 1.0; coerce := (a::float) -> a; absolute := (a) -> abs(a); sine := (a) -> sin(a); sqroot := (a) -> sqrt(a); end module: Abstract Data Type ApproachData Type Approach Module does not store data, provides only the operations As a convention one must coerce the float type to the representation used by this module In this case the representation is exactly float DoubleRing module created only once for each kernel